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(54) Method and system for processing video incorporating multiple on screen display formats 



(57) A data format (67) employing multiple different 
headers (1 36) associated with corresponding OSD con- 
tent (138) facilitates the implementation of an efficient 
and flexible OSD management and control system. 
Each header (1 36) contains a unique display character- 
istic or set of display characteristics for the interpretation 



and presentation of an associated OSD pixel map (1 38). 
In using this system, the presentation or modification of 
an OSD (1 38) involves the selection of the header ( 1 38), 
associated with the OSD (1 38), having the desired dis- 
play characteristics to be used in presenting or modify- 
ing the OSD (138). 
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Description 

[0001] The present invention relates to video data 
processing. 

[0002] Home entertainment systems which combine 
Personal Computer and television functions (PC/TV 
systems), are increasingly becoming generic user-inter- 
active multiple -source and multiple-destination commu- 
nication devices. Such multimedia systems are required 
to communicate in different data formats between mul- 
tiple locations for a variety of applications in response 
to user requests. For example, a PC/TV system may re- 
ceive data from satellite or terrestrial sources compris- 
ing High Definition Television (HDTV) broadcasts, Multi- 
point Microwave Distribution System (MMDS) broad- 
casts and Digital Video Broadcasts (DVB). A PC/TV sys- 
tem may also receive and transmit data via telephone 
(e.g., the Internet) and coaxial lines (e.g., cable TV) as 
well as from both remote and local sources such as Dig- 
ital Video Disk (DVD), CDROM, VHS and Digital VHS 
(DVHS™) type players, and PCs. 
[0003] Such a generic PC/TV entertainment system 
requires a variety of different On Screen Displays 
(OSDs) for use with video program content from differ- 
ent sources or for different applications. The processing 
of multiple different OSDs in television and multimedia 
systems is constrained by time, memory size, and other 
practical limitations. A system according to the present 
invention provides an OSD management and control 
system that efficiently accommodates the data process- 
ing constraints. 

[0004] A data format employing multiple different 
headers associated with corresponding OSD content fa- 
cilitates the implementation of an efficient and flexible 
OSD management and control system. Each header 
contains a unique display characteristic or set of display 
characteristics for the interpretation and presentation of 
an associated OSD pixel map. In using this system, the 
presentation or modification of an OSD involves the se- 
lection of the header, associated with the OSD, having 
the desired display characteristics to be used in present- 
ing or modifying the OSD. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0005] In the drawings: 

FIG. 1 shows an exemplary home entertainment 
system for processing OSD header and content da- 
ta according to the present invention; 
FIG. 2 further illustrates the MPEG decoder and vid- 
eo memory of the exemplary home entertainment 
decoder system shown in FIG. 1; 
FIG. 3 illustrates a conventional MPEG decoder 
and video memory arrangement; 
FIG. 4 is a flowchart illustrating a conventional OSD 
retrieval process; 

FIG. 5 illustrates conventional OSD data formats; 



FIG. 6 illustrates an MPEG decoder and video 
memory arrangement of the present invention; 
FIG. 7 is a flowchart illustrating the OSD retrieval 
process of the present invention; and 
s FIG. 8 illustrates the OSD data format of the present 
invention. 

[0006] The characteristics and advantages of the 
present invention will become more apparent from the 
following description, given by way of example. 
[0007] Referring now to FIG. 1 , a block diagram of an 
exemplary digital video receiving system that operates 
according to the principles of the invention is shown. The 
video receiver system includes an antenna 1 0 and input 
processor 15 for receiving and digitizing a broadcast 
carrier modulated with signals carrying audio, video, 
and associated data, a demodulator 20 for receiving and 
demodulating the digital output signal from input proc- 
essor 1 5, and a decoder 30 outputting a signal that is 
trellis decoded, mapped into byte length data segments, 
de-interleaved, and Reed-Solomon error corrected. The 
corrected output data from decoder unit 30 is in the form 
of an MPEG compatible transport datastream contain- 
ing program representative multiplexed audio, video, 
and data components. 

[0008] The video receiver system further includes a 
modem 80 that may be connected, via telephone lines, 
to a server 83 or connection service 87 such that data 
in various formats (e.g., MPEG, HTML, and/or JAVA) 
can be received by the video receiver system over the 
telephone lines. 

[0009] A processor 25 processes the data output from 
decoder 30 and/or modem 80 such that the processed 
data can be displayed on a display unit 75 or stored on 
a storage medium 105 in accordance with requests in- 
put by a user via a remote control unit 125. More spe- 
cifically, processor 25 includes a controller 115 that in- 
terprets requests received from remote control unit 125 
via remote unit interface 120 and appropriately config- 
ures the elements of processor 25 to carry out user re- 
quests (e.g., channel, website, and/or OSD display). In 
one exemplary mode, controller 115 configures the ele- 
ments of processor 25 to provide MPEG decoded data 
and an OSD for display on display unit 75. In another 
exemplary mode, controller 15 configures the elements 
of processor 25 to provide an MPEG compatible datast- 
ream for storage on storage medium 105 via storage 
device 90 and store interface 95. In a further exemplary 
mode, controller 115 configures the elements of proces- 
sor 25 for other communication modes, such as for re- 
ceiving bi-directional (e.g. Internet) communications via 
server 83 or connection service 87. 
[001 0] Processor 25 includes a decode PI D selection 
unit 45 that identifies and routes selected packets in the 
transport stream from decoder 30 to transport decoder 
55. The transport stream from decoder 30 is demulti- 
plexed into audio, video, and data components by trans- 
port decoder 55 and is further processed by the other 
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elements of processor 25, as described in further detail 
below. 

[0011] The transport stream provided to processor 25 
comprises data packets containing program channel 
data, ancillary system timing information, and program 
specific information such as program content rating and 
program guide information. Transport decoder 55 di- 
rects the ancillary information packets to controller 115 
which parses, collates, and assembles the ancillary in- 
formation into hierarchically arranged tables. Individual 
data packets comprising the user selected program 
channel are identified and assembled using the assem- 
bled program specific information. The system timing in- 
formation contains a time reference indicator and asso- 
ciated correction data (e.g. a daylight savings time indi- 
cator and offset information adjusting for time drift, leap 
years, etc.). This timing information is sufficient for a de- 
coder to convert the time reference indicator to a time 
clock (e.g., United States east coast time and date) for 
establishing a time of day and date of the future trans- 
mission of a program by the broadcaster of the program. 
The time clock is useable for initiating scheduled pro- 
gram processing functions such as program play, pro- 
gram recording, and program playback. Further, the pro- 
gram specific information contains conditional access, 
network information, and identification and linking data 
enabling the system of FIG. 1 to tune to a desired chan- 
nel and assemble data packets to form complete pro- 
grams. The program specific information also contains 
ancillary program content rating information (e.g., an 
age based suitability rating), program guide information 
(e.g., an Electronic Program Guide - EPG) and descrip- 
tive text related to the broadcast programs as well as 
data supporting the identification and assembly of this 
ancillary information. 

[0012] Transport decoder 55 provides MPEG compat- 
ible video, audio, and sub-picture streams to MPEG de- 
coder 65. The video and audio streams contain com- 
pressed video and audio data representing the selected 
channel program content. The sub-picture data contains 
information associated with the channel program con- 
tent such as rating information, program description in- 
formation, and the like. 

[0013] MPEG decoder 65 cooperates with a random 
access memory (RAM) 67 to decode and decompress 
the MPEG compatible packetized audio and video data 
from unit 55 and provides decompressed program rep- 
resentative pixel data to display processor 70. Decoder 
65 also assembles, collates and interprets the sub-pic- 
ture data from unit 55 to produce formatted program 
guide data for output to an internal OSD module (See 
FIGS. 2, 3, and 6). The OSD module cooperates with 
RAM 67 to process the sub-picture data and other infor- 
mation to generate pixel mapped data representing sub- 
titling, control, and information menu displays including 
selectable menu options and other items for presenta- 
tion on display device 75 in accordance with the present 
invention. The control and information menus that are 



displayed enable a user to select a program to view and 
to schedule future program processing functions includ- 
ing tuning to receive a selected program for viewing, re- 
cording of a program onto storage medium 105, and 
s playback of a program from medium 1 05. 

[001 4] The control and information displays, including 
text and graphics produced by the OSD module, are 
generated in the form of overlay pixel map data under 
direction of controller 115. The overlay pixel map data 
10 from the OSD module is combined and synchronized 
with the decompressed pixel representative data from 
MPEG decoder 65 under direction of controller 115. 
Combined pixel map data representing a video program 
on the selected channel together with associated sub- 
's picture data is encoded by display processor 70 and out- 
put to device 75 for display. 

[001 5] The principles of the invention may be applied 
to terrestrial, cable, satellite, Internet or computer net- 
work broadcast systems in which the coding type or 

20 modulation format may be varied. Such systems may 
include, for example, non-MPEG compatible systems, 
involving other types of encoded datastreams and other 
methods of conveying program specific information. 
Further, although the disclosed system is described as 

25 processing broadcast programs, this is exemplary only. 
The term 'program' is used to represent any form of 
packetized data such as audio data, telephone messag- 
es, computer programs, Internet data or other commu- 
nications, for example. 

30 [0016] The architecture of Figure 1 is not exclusive. 
Other architectures may be derived in accordance with 
the principles of the invention to accomplish the same 
objectives. Further, the functions of the elements of 
processor 25 of Figure 1 may be implemented in whole 

35 or in part within the programmed instructions of a micro- 
processor. In addition, the principles of the invention ap- 
ply to any form of MPEG or non-MPEG compatible elec- 
tronic program guide. 

[0017] Referring now to FIG. 2, MPEG decoder 65 

40 and video RAM 67 are illustrated in further detail. De- 
coder 65 includes a FIFO buffer memory 130 which re- 
ceives video data packets on demand in small segments 
from transport decoder 55 and couples them into rela- 
tively larger segments via a memory controller 1 32 to a 

45 section 1 34 of RAM 67 reserved for decoding and de- 
compression. Video RAM 67 is addressed under the 
control of memory controller 1 32. Section 1 34 of RAM 
67 includes a rate buffer section for storing the received 
video data packets and a frame store section for storing 

so frames of video information during the decoding and de- 
compression operation. A video display unit 140 de- 
codes and decompresses the stored video data packets 
to form a sequence of video image components. For this 
purpose, video display unit 140 requests data from the 

55 decoding and decompression portion of section 1 34 via 
memory controller 132 as required. The sequence of 
video image components are synchronized with field, 
line, and pixel rate signals generated by display proces- 
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sor 70. Control data generated by controller 115 is re- 
ceived by controller interface unit 142 and coupled to 
various elements of MPEG decoder 65 via an internal 
control bus. 

[0018] The OSD portion of MPEG decoder 65 in- 
cludes an OSD display unit 144 which communicates 
with an OSD header memory block 136 and an OSD 
pixel map or bitmap memory block 1 38 of RAM 67 via 
memory controller 1 32, as discussed in further detail be- 
low. Upon initialization of the video receiver, controller 
115 generates a plurality of pixel maps and associated 
pixel map headers and stores them in OSD pixel map 
and OSD header blocks of memory 138 and 136 via con- 
trol interface 142 and memory controller 132. 
[001 9] An output multiplexer 1 46, under the control of 
OSD display unit 1 44, combines the output of video dis- 
play unit 140 (video image components) and the output 
of OSD display unit 144 (graphic image components) 
and passes the video and graphical combination to dis- 
play processor 70 for display on display unit 75. 
[0020] Referring now to FIG. 3, a conventional OSD 
management and control arrangement is shown. Mem- 
ory controller 132 includes, inter alia, an OSD header 
pointer (OHP) register 1 48 and a memory access file 
(MAF) register 1 50 for facilitating the storage and re- 
trieval of OSD data in OSD header block 136 and OSD 
pixel map block 138 of memory 67. Memory controller 
132 manages the storage and retrieval of OSD data in 
memory 67 in response to requests from OSD display 
unit 144. Upon initialization of the video receiver, a plu- 
rality of OSD data structures are stored in memory 67. 
Each OSD data structure includes an OSD header (e. 
g., "OSD 1", "OSD 2", and "OSD 3" headers) stored in 
header block 1 36 of memory 67 and an OSD pixel map 
(e.g. , "OSD 1 ", "OSD 2", and "OSD 3° pixel maps) stored 
in pixel map block 1 38 of memory 67. In accordance with 
the conventional OSD buffering technique, there is a 
single OSD header stored in header block 136 for each 
OSD pixel map stored in pixel map block 1 38. Each OSD 
header contains the memory location of the associated 
pixel map in pixel map block 138 as well as a set of dis- 
play characteristics that define how the associated pixel 
map is to be processed by display processor 70 and dis- 
played on display unit 75. For example, the a OSD 1 n 
header contains the memory location of the "OSD 1 ■ pix- 
el map as well as a set of display characteristics defining 
how the "OSD 1 D pixel map is to be processed and dis- 
played. The display characteristics include, but are not 
limited to, the presence or absence of OSD side panels, 
the use of pixel compression, the number of bits per pix- 
el, YUV or YIQ colorimetry, degree of transparency, 
OSD size, OSD format (e.g., interlaced or progressive), 
OSD cotor scheme, OSD blending ratio, OSD resolu- 
tion, aspect ratio, horizontal pixel duplication, vertical 
pixel duplication, OSD screen location. Some exempla- 
ry OSD header and OSD pixel map data structures are 
illustrated in FIG. 5. As discussed above, each OSD 
header 167 is associated with a different OSD pixel map 



168. 

[0021] Referring now to FIG 4, in conjunction with 
FIG. 3, a conventional OSD retrieval process 151 is 
shown. Initially, OSD display unit 144, at step 152, re- 

5 ceives an OSD display request from controller 115 to 
display an OSD (e.g., a graphical image as shown in 
FIG. 5) on display unit 75. In response to the controller's 
request OSD display unit 144, at step 154, transmits a 
memory access request to OHP register 148. OHP reg- 

10 ister 148 services the request, at step 156, by writing 
the OSD header corresponding to the desired OSD pixel 
map into MAF register 150. OSD display unit 144, at 
step 158, reads the OSD header to determine the loca- 
tion of the OSD pixel map in pixel map block 1 38. Once 

is the pixel map location is determined, OSD display unit 
1 44 sets the OSD address in memory controller 1 32 and 
requests that memory controller 1 32 read the image at 
the set address into MAF register 1 50. Afterwards, OSD 
display unit 144, at step 160, determines if the display 

20 characteristics in the retrieved OSD header comply with 
the display characteristics of the OSD display request. 
For example, the display characteristics of the retrieved 
header may indicate that the associated pixel map is to 
be displayed as a blue image in an upper portion of dis- 
ss play 75 while the requested display characteristics are 
for the associated pixel map to be displayed as a green 
image in a lower portion of display 75. If the display char- 
acteristics of the OSD header comply with the requested 
OSD display characteristics, OSD display unit 1 44, at 

30 step 1 62, passes the OSD pixel map and the associated 
display characteristics (as provided in the OSD header) 
to display processor 70. If the display characteristics of 
the OSD header do not comply with the requested OSD 
display characteristics, OSD display unit 144, at step 

35 1 64, rewrites the display characteristics in the retrieved 
OSD header and/or redraws the OSD pixel map to con- 
tain the requested display characteristics before pass- 
ing, at step 166, the OSD pixel map (as redrawn) and 
associated header (as rewritten) to display processor 

40 70. The rewriting of the OSD header and/or redrawing 
of the OSD pixel map results in a delay between the 
OSD request from controller 115 and the display of the 
OSD having the desired display characteristics. In other 
words, the multiple memory instructions required to 

45 modify the OSD header and associated OSD pixel map 
results in a delay in the display of the OSD. It should be 
noted that if the OSD display request occurs when the 
video receiver is involved in a time critical process (e. 
g. , the display of a video program), a delay in the display 

so of the OSD may result in a disruption or distortion of the 
video (e.g., the introduction of video anomalies) being 
displayed to a user. 

[0022] Referring now to FIG. 6, an improved OSD 
management and control arrangement of the present in- 
55 vention is illustrated. The improved OSD management 
and control arrangement of the present invention greatly 
reduces the delay that would otherwise be encountered 
using the conventional OSD management and control 
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arrangement of FIG. 3. In accordance with the arrange- 
ment of the present invention, a plurality of OSD data 
structures are stored in memory 67 upon initialization of 
the video receiver. More specifically, each OSD data 
structure of the present invention includes an OSD pixel 
map stored in pixel map block 1 38 of memory 67 and a 
plurality of associated OSD headers stored in header 
block 136 of memory 67. Thus, in accordance with the 
OSD buffering technique of the present invention, there 
are a plurality of OSD headers (e.g., "OSD 1 a 0 , B OSD 
1 b°, and "OSD 1 c n headers) stored in header block 1 36 
for each OSD pixel map (e.g., "OSD 1 " pixel map) stored 
in pixel map block 138. Each OSD header contains the 
memory location of the associated OSD pixel map and 
a unique display characteristic or set of display charac- 
teristics defining how the OSD pixel map is to be dis- 
played on display unit 75. An exemplary multiple OSD 
header 1 92 and single OSD pixel map 1 94 data struc- 
ture 190 is illustrated in FIG. 8. 
[0023] Referring now to FIG. 7, in conjunction with 
FIG. 6, an OSD retrieval process 170 of the present in- 
vention is shown. Initially, OSD display unit 144, at step 
172, receives an OSD display request from controller 
1 1 5. In response to the controller's request, OSD display 
unit 144, at step 174, transmits a memory access re- 
quest to OHP register 148. OHP register 148 services 
the request, at step 176, by writing the OSD header cor- 
responding to the desired OSD bitmap and complying 
with the requested display characteristics into MAF reg- 
ister 150. OSD display unit 178, at step 158, reads the 
OSD header to determine the location of the OSD pixel 
map in pixel map block 1 38. Once the pixel map location 
is determined, OSD display unit 144 sets the OSD ad- 
dress in memory controller 1 32 and requests that mem- 
ory controller 1 32 read the image at the set address into 
MAF register 150. Afterwards, OSD display unit 144, at 
step 1 80, passes the OSD pixel map and the associated 
display characteristics (as provided in the OSD header) 
to display processor 70. It should be noted that there is 
no rewriting of the OSD header or redrawing of the OSD 
pixel map since multiple headers for each pixel map are 
provided. Preferably, there are as many headers as 
there are combinations of display characteristics for the 
associated pixel map. Thus, an OSD may be retrieved 
from memory 76 using a single memory instruction from 
OSD display unit 144 (as opposed to the multiple in- 
structions that would otherwise be required for the re- 
trieval and rewriting of an OSD header having incorrect 
display characteristics). Moreover, providing a plurality 
of headers (with each header having a unique display 
characteristic or set of display characteristics) for each 
pixel map facilitates efficient OSD selection, OSD mod- 
ification, and OSD display without a rewriting and/or re- 
drawing delay. 

[0024] While the present invention has been de- 
scribed with reference to the preferred embodiments, it 
is apparent that that various changes may be made in 
the embodiments without departing from the spirit and 



the scope of the invention, as defined by the appended 
claims. 



s Claims 

1 . A method for processing image data for display, the 
method characterized by the steps of: 

10 storing a pixel map in a memory; 

storing a plurality of different headers associat- 
ed with the pixel map in the memory; and 
selecting a header defining a desired display 
characteristic for the pixel map. 

15 

2. The method of claim 1 , further characterized by the 
step of: 

processing the selected header and associat- 
ed pixel map to generate an image in a displayable 
format. 

3. The method according to claim 1, characterized in 
that the pixel map is associated with an on-screen 
display (OSD) data structure. 

4. The method of claim 1 , characterized in that the de- 
sired display characteristic is at least one of a pres- 
ence or absence of a side panel, a YUV or YIQ 
colorimetry, a degree of transparency, an image 
size, an interlaced or progressive display format, a 
color scheme, an aspect ratio, a blending ratio, a 
resolution factor, a number of bits per pixel, a com- 
pression factor, a horizontal pixel duplication value, 
and a vertical pixel duplication value. 

5. A method of generating an image for display on a 
display unit, the method characterized by the steps 
of: 

receiving a request to display an image having 
a desired display characteristic; 
accessing an image data structure stored in a 
memory in response to the received request, 
the image data structure including an image 
block containing image data and a plurality of 
associated header blocks, each header block 
containing the memory location of the image 
block and a unique image display characteris- 
tic; 

selecting a header block having a unique dis- 
play characteristic that corresponds to the de- 
sired display characteristic; and 
processing the selected header block and the 
associated image block such that the image 
having the desired characteristic is displayed. 

6. The method of claim 5, characterized in that the im- 
age is an on-screen display. 
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7. The method of claim 5, characterized in that the dis- 
play characteristic is at least one of a presence or 
absence of a side panel, a YUV or YIQ colorimetry, 
a degree of transparency, an image size, an inter- 
laced or progressive display format, a color s 
scheme, an aspect ratio, a blending ratio, a resolu- 
tion factor, a number of bits per pixel, a compression 
factor, a horizontal pixel duplication value, and a 
vertical pixel duplication value. 

10 

8. The method of claim 5 characterized in that the dis- 
play characteristic is a unique set of display char- 
acteristics. 

9. The method of claim 5, further characterized by the is 
step of: 

storing the data structure in the memory prior 
to the receipt of the image display request. 

1 0. The method of claim 5, characterized in that the im- 20 
age data structure is one of a plurality of image data 
structures stored in the memory. 

11. The method of claim 5, characterized in that the im- 
age data in the image block of the image data struc- 25 
ture is a pixel map. 

12. In a system for the reception, processing, and dis- 
play of video and graphical data, a method of gen- 
erating an on-screen display; characterized by 30 

storing a data structure in a memory upon an 
intialization of the system, the data structure in- 
cluding on-screen display content data and a 
plurality of headers associated with the on- -35 
screen display content data, each header con- 
taining a distinct set of processing instructions 
for the processing of the on-screen display con- 
tent data; 

receiving a request to display an on-screen dis- 40 
play corresponding to the stored data structure, 
the request indicating that the on-screen dis- 
play is to be displayed in accordance with a se- 
lected format; 

retrieving the on-screen display content data 45 
and a header of the plurality of headers from 
the memory in response to the received re- 
quest, the retrieved header containing a distinct 
set of processing instructions that correspond 
to the selected format; and 50 
processing the retrieved on-screen display 
content data in accordance with the distinct set 
of processing instructions of the retrieved 
header to generate the on-screen display in the 
selected format. ss 

13. The method of claim 12, characterized in that the 
distinct set of processing instructions includes an 



instruction for at least one of a presence or absence 
of a side panel, a YUV or YIQ colorimetry, a degree 
of transparency, an image size, an interlaced or pro- 
gressive display format, a color scheme, an aspect 
ratio, a blending ratio, a resolution factor, a number 
of bits per pixel, a compression factor, a horizontal 
pixel duplication value, and a vertical pixel duplica- 
tion value. 

14. The method of claim 12, charactered in that the on- 
screen display content data is a pixel map. 

15. A system for generating an image, the system char- 
acterized by: 

an input coupled to a source of image requests, 
each image request containing a desired image 
and desired image characteristic; 
a memory for storing a plurality of image data 
structures, each image data structure including 
an image segment and a plurality of associated 
header segments, each header segment in- 
cluding a unique image characteristic; 
a controller coupled to the input and the mem- 
ory, the controller accessing an image data 
structure of the plurality of image data struc- 
tures in response to an image request received 
from the input, the controller accessing the im- 
age data structure such that the image segment 
corresponding to the desired image and the as- 
sociated header segment corresponding to the 
desired image characteristic are retrieved from 
the memory; and 

processing circuitry coupled to the controller for 
receiving the retrieved image segment and 
header segment from the controller and 
processing the image segment in accordance 
with the header segment to generate an image 
corresponding to the image request. 

16. The system of claim 15, further characterized by: 

a display unit coupled to the processing cir- 
cuitry for displaying the image generated by the 
processing circuitry. 

17. The system of claim 15, characterized in that the 
image segment is a pixel map. 

18. The system of claim 15, characterized in that the 
unique image characteristic is at least one of a pres- 
ence or absence of a side panel, a YUV or YIQ 
colorimetry, a degree of transparency, an image 
size, an interlaced or progressive display format, a 
color scheme, an aspect ratio, a blending ratio, a 
resolution factor, a number of bits per pixel, a com- 
pression factor, a horizontal pixel duplication value, 
and a vertical pixel duplication value. 
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19. The system of claim 15, characterized in that the 
image corresponding to the image request is an on- 
screen display. 

20. The system of claim 1 5, characterized in that the s 
unique image characteristic is a unique set of image 
characteristics. 

21. An on-screen display memory characterized by: 

10 

a first region containing a pixel map; 
a second region containing a plurality of differ- 
ent headers respectively defining different dis- 
play characteristics for the pixel map; and 
a control port for selecting a desired one of the *5 
different headers. 
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